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ABSTBACT THE DISCLOSURE 



TITLE OF THE WVEHTION 



MULTI-PROTOCOL IP PHONE 

FiELD OF THE INVENTION 

The present invention relates to voice over Internet 
protocols (VoiP). More specifically, the present invention is concerned 
with a rouiti-protoco! IP phone. 

BACKGROUND OF JHg INVENTION 

Voice over the Internet protocols (VoiP) enables 
transmission of the voice over the internet. This technology provides an 
alternative and ultimately someday s replacement to public switch 
telephone networks (PSTN). 

Many Voir signalling protocois are known including for 
example; Session Initiation Protocol {SiP} (RFC 2543). Media Gateway 
Control Protocol (MGCP) {RFC 2705), Megaco Protocol {RFC 30 15) and 
HL323. 

Many major telephony companies are researching (and 
eventually deploying) more than one signalling protocol However. 

.els are designed independently and usually do not have 
built-in translation from one to the other. Ever, if translators between those 
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protocols are being developed, there are potential benefits to have a 
device that supports multiple signaiiing protocols simultaneously. 

Moreover, current VoiP either enable s single phone acting 
6 ss a peer in a peer-to-peer architecture or as a slave in a master-slave 
architecture Usually, the total control of the phone implied by the master- 
siave architecture would make it impossible for an IP phone to 
simultaneously act as a slave and as a peer. 

10- Indeed, on some master-slave architecture (like In iVsGCP or 

Megaco) the master knows every event occurring on the IP phone, the 
1 a plied or, the IP phone. The problem 
that arises, when an MGCP IP phone wants to support s peer-to-peer 
protocol like SIP. is thai the signals and events needed for the peer-tg- 

1 5 peer protocol conflict with those managed by the master. 

For example, when a user picks up a phone implementing 
the MGCP to make a call, the Caii-Agent (the master in a MGCP network) 
is notified of the "off hook" event and asks the MGCP phone to generate 

20 a "dial tone* signal, if a peer-to-peer device such as a SiP User Agent, 
tries to call the same phono, the Calf-Agent wiii not be aware of It since the 
different signaiiing protocols are not aware of each other. When the 
MGCP phone receives the SIP Invitation for a call it should start to ring. 
The MGCP Caii-Agent does not request this "ring" signal This would 

25 usually work, but when the user will pick up the phone to answer the SIP 
call, the Call-Agent must not be notified of this "off hook" event because 
no "dial tone" signal must be applied. If the phone goes "off hook" without 



the Cali-Agent knowing it, the Call-Agent continues to consider the phone 
"on hook" and couid possibly accept an incoming MGCP call and try to 
make the phone ring until it is notified of an "off hook" transition (which will 
never happen since She phone is already "off hook"). The problem 
5 described here between a peer-to-peer protocol and a master-slave 
protocol, can also occur between two master-slave protocois. if an iP 
phone is managed for example by a MGCP Call-Agent end is also 
managed by a Megaco Ceii-Agent, the same kind of conflict will happen 
In the management of the events and signals. 

10 

By default every signalling protocol listens on a different 
User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) 
port. For example, MGCP gateways currently listen on UDP port 2427, 
SIP User Agents listen on UDP port 5040 and MEGACO gateways listen 

15 an UDP port 2944 or 2945. Therefore, there is no problem running 
- _ , . j : s such as SIP. MGCP and Megaco simultaneously on 
one device because the signalling messages are de-multiplexed at the 
U'DP/TCF layer. However, one of the drawbacks of devices from the prior 
art is the concurrent control t s g dco! wants ors s singie device 

20 (IP phone). 

According to a first embodiment of the present invention, 
25 there is provided a multi-protocol IP phone thai is configured to 
simultaneously receive calls from a plurality of supported signalling 
protocols such as SIP, MGCP and Megaco and to make a call using any 
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of the supported signalling protocols. This is achieved by hiding the 
events and signals of one signaling protocol from the other supported 
Signalling protocols. The segregation also applies to the media flow. 

5 The signalling protocol segregation is advantageously 

realised through a user interface, indeed, in addition to the traditional 
phone interface that includes dual tone multifrequency (DTMF) buttons, 
flash button, hold button, etc., the multi-protocol IP phone includes other 
user interface elements that allow selection, information on status and/or 
1 0 other operation on a particular signalling protocol. 

For example, a "line Sutton" for each supported signalling 
protocol. This "Line Button" advantageously includes a light to indicate the 
usage of the line. In addition to the "Line Button", an IP phone, according 
IS to the first embodiment of the present invention, also includes "Hold" and 
"Speaker" buttons that regulate the IP phone operation outside the control 
of the signalling protocol. 

Other interface elements may also be provided to allow 
20 different functions for each of the protocols implemented on the IP phone. 

The IP phone may take many forms, from a device having 
a design similar to a traditional phone, to a software Implementation on a 
computer. 

25 



According to the first embodiment of the present invention, 
each protocol that is implemented on the IP phone controls a virtual IP 
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phone inside the physical IP phone. For example, inside 3 mufti-protocol 
IP phone supporting SIP, MGCP and yegaco, there would be one virtual 
SIP IP phone, one virtuai MGCP IP phone, and one virtual fvfegaco IP 
phone. These virtual IP phones share the unique resource of the physical 
!P phone without their respective signalling protocol being "aware" of the 
implementators oi the other signalling protocols. 

According to the first embodiment of the present invention, 
there is only one user interface (phone interface) and the user can interact 
with onty one virtual IP phone at the time. Therefore, only one virtual IP 
phone can be active at the time. The user will be able decide which virtual 
IP phone is active by using the "Line Burton*. 

When one of the virtual IP phones is active, atf user 
interactions, excluding usage of the interface elements that regulate the 
IP phone operation outside the control of ihe signalling protocol, such as 
the "Line Button", "Hoid Sutton" and "Speaker Button", are reflected as 
events in the virtual IP phone. Signals requested to an active virtuai SP 
phone are applied to the physical IP phone as if no other signalling 
protocol was implemented. 

Since user input is allowed only for the active virtual I? 
phone, no event is ever received in an inactive virtual IP phone. Signals 
requested to an inactive virtuai IP phone are not applied to the physical IP 
phone. For example,, brief signals (DTMF) applied on an inactive virtual IP 
phone are lost forever, as they would be if the user were away from the 
phone when they were played. Other signals {"dial tone", "ring back tone", 
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"busy tone"., etc.) are advantageously memorized but not generated in the 
physical iP phone. The related signalling protocol doesn't know that the 
signals do not reach the user, if the signals have to step before the virtual 
IP phone ever becomes active, the user will never know they were 
5 requested. If the virtual IP phone becomes active before the end of the 
signals, then, the signals are applied to the physical IP phone, as they 
would normally he. An exception to this rule is when the signalling protocol 
needs the virtual IP phone to ring while it is inactive. In this case, instead 
of applying a normal ring to the physical iP phone, a single brief ring will 
10 be applied to the physical phone and the light of the "Line Button" 
associated with the signalling protocol wii! flash. 

Few rules are required to regulate which virtual IP phone is 
active. Since the signalling protocols are unaware of the concept of an 
1 5 active virtual IP phone, they advantageously do not request the activation 
and deactivation of the virtual IP phones. 

Some of the triggers for activation/deactivation may not 
even be implemented in a particular signalling protocol. The usage of "Line 
20 Sutton", "Hold Button" and "Speaker Button" that are often part of the user 
interface of a conventionally PSTN phone doesn't make sense in the 
signalling protocol context. 

Other events that are implemented in some signalling 
25 protocols activate or deactivate 3 virtual IP phone as a transparent side 
effect. For example, when a call is received for a s 
protocol the ring" signs s requested on the appropriate virtual IP phone. 
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if no other virtual IP phone is active, the ringing virtue! IP phone becomes 
active. Not only does the physical IP phone now ring, but when the user 
will pick up the phone, it will also automatically be in the active virtuai IP 
phone and answer the received call. Another example o? implicit activation 
5 is when the user picks up the phone and no virtual IP phone is presently 
active, the default virtuai IP phone becomes active and receives the "off 
hook" event 

The combination of an active virtual IP phone arid events 
10 hidden from the signaling protocols ailow services such as making an 
MGCP call, putting it on hold to answer a received SIP call, and switching 
between the two without interaction between the SIP and MGCP signalling 
protocols. 

15 The IP phone according to the present invention may 

Include a virtual IP phone manager, advantageously in the form of 
software, to abstract the physical SP phone from each signalling protocol. 

A multi-protocol IP phone, according to embodiments of the 
20 present invention, could either have a unique phone number (u&abfe by 
a user of any supported signalling protocol) or have one different phone 
number by supported signalling protocol. 




For example, in SIP, the mapping between the phone 
25 number and the !P address and port of the phone is done In a SIP 
Redirect Sewer. In MGCP and fviegaco, the mapping In done through the 
Call-Agent. If all of these databases are independent, it is possible to have 



the same phone number in each database for a unique muiti-protocoi IF 
Phone. In each database, Shis unique phone number would refer to the 
same IP address, but So a different port number (the port number depends 
on the signaling protocol). This is advantageous since it allows the multi- 
protocol iP Phone user to give one single phone number, which is 
reachable by ever/ supported signalling protocol 

According to a second embodiment of the present invention, 
there is provided an IP Phone having multiple MGCP endpoints without 
the Call-Agent ever knowing, resulting in multiple MGCP lines with their 
own individual phone number inside the IP Phone, 

According to a third embodiment of the present Invention, 
the supported signalling protocols are managed in the residential gateway 
and the "Virtual IP Phone Manager" is also located in the residential 
gateway. 

Although the present invention as been described by way of 
reference to a phone, it is believed to be within the reach of a person 
skied in the art to apply the teaching of this first embodiment to conceive 
a multi-protocol fax machine or a multi-protocol wiretap. 

A multi-protocol fax, according to the present invention, 
could be in the form of hardware such as a conventional fax, or could 
alternatively be in the form of a computer so programmed as to receive a 
fax message from any of the predetermined signalling protocols and print 
the message or convert it into a computer readable format such as TIFF 



( i ag image Fife Format}, 



A muffi-protocol wiretap according to the present invention 
would allow copying of the mixed media Sow and wouid forward it, for 
5 example, to a server via an IP network such as the Internet. The server 
would advantageously be configured to backup the phone conversation 
and relay it upon demand to a remote computer. 

Although the present invention has been described 
10 hereinabove by way of preferred embodiments thereof, it cars be modified 
without departing from the spirit and nature of the subject invention, as 
defined in ihe appended claims. 



WHAT IS CLAIMED 8S: 

1. A muiti-prctocof iP phone as described in the present 

application. 

2. A mufti-protocol IP fax as described in the present 

application. 

3. A mtsiti.-prQtocoi wiretap as described in the present 

application. 



